The Internet comprises a vast number of computers interconnected so that information can be exchanged among the computers. Various protocol and other interface standards have been developed for the Internet so that each computer will understand information of the other computers. The World-Wide Web ("WWW") is a subset of the Internet computers that support the Hypertext Transfer Protocol ("HTTP"). HTTP is an application-level protocol for distributed, collaborative, hyper-media information systems that defines the format and contents of messages and responses sent between client programs ("clients") and server programs ("servers") over the Internet. In addition, HTTP is a generic, stateless, object-oriented protocol which can be used for many other tasks, such as name servers and distributed object management systems, through various extensions.
The Internet facilitates information exchange between servers and clients that are located throughout the world. Each computer on the Internet has a unique address (e.g., "acme.com"). When a client wishes to access a resource (e.g., document), the client specifies a Uniform Resource Locator ("URL") that uniquely identifies the computer on which the server executes and the resource. An example of a URL is "http://acme.com/page1." In this example the server is identified by "acme.com" and the resource is identified by "page1." The URL has two parts: a scheme and a scheme-specific part. The scheme identifies the high-level protocol through which the information is to be exchanged, and the scheme-specific part contains additional information that identifies the server computer and the resource. The "http" at the beginning of the example URL is the scheme and indicates that the remainder of the URL should be interpreted according to HTTP. The remainder specifies a server computer (e.g., "acme.com") followed by additional information that is specific to the server. For example, the additional information may be a path name within the server computer to a Hypertext Markup Language ("HTML") document.
HTTP is based on a request/response paradigm. An HTTP message consists of a request from a client sent to a server and a response sent from the server to the client. A client sends a request to the server in the form of a request line comprising a method (e.g., "GET") and a URL, optionally followed by a request header that allows the client to pass additional information about the request, a general header that allows a client to specify optional behavior that can be performed by the server, and an entity header and entity body that allow the client to send arbitrary information that is understood by a server. The server responds with a status line indicating status of the request (e.g., success or fail) followed by a response header that allows the server to send additional information to a client, and a general header, entity header, and entity body that is analogous to those sent in the request. The request line of an HTTP request begins with a method token followed by a request URL. HTTP defines three request line methods that include "get," "head," and "post." HTTP further defines extension methods. The status line of an HTTP response includes a status code and a user readable reason phrase that indicates the status of the request. The headers generally contain a list of fields that include a field name, a colon, and a field value.
HTTP has been extended to permit a client to specify that a computer program is to be executed by the server. Two such extensions are the Common Gateway Interface ("CGI") and the Internet Server Application Programming Interface ("ISAPI"). CGI defines a sub-protocol of HTTP for running external softwares or gateways under a server in a platform-independent manner. A URL in an HTTP request specifies not only the protocol and server computer, but also a script, a behavior of the script, and parameters to pass to the script. When a server using CGI receives a URL, it recognizes that the client is requesting that a script be invoked. The server parses the information from the HTTP request and stores the information in "environment variables." For example, an environment variable named "scriptlname" contains the name of the script to be executed, and the environment variable named "content.sub.-- length" contains the length of the entity body attached to the request. The server also invokes the specified script. The executing script can then request the various environment variables to be supplied by the server. Although the CGI and ISAPI protocols specify the format and semantics of executing a computer program at servers, they do not specify how to implement such server or scripts.
Because a client can specify a program to execute, there is a possibility that a client may request execution of a program for which it is not authorized or that may cause serious problems on the server computer. For example, if a client sends to a server a file that contained a program to erase a disk drive and requests that it be stored on the server computer. The client might then request that the client execute that file, which would result in erasure of the disk drive. Although servers could be developed to ensure that no such programs can be executed, currently typical servers do not provide such assurances. It would be desirable to have a mechanism that would allow existing servers to provide such assurances.